daynaport-68000-fix

A fix for the "Sorry, a system error occurred. address error" that a 68000 Mac (Plus, SE, Classic) hits at startup when AppleTalk is set to EtherTalk through a DaynaPORT SCSI/Link, real or emulated by a BlueSCSI, ZuluSCSI or PiSCSI.

• System 6 with AppleTalk 58 and the DaynaPORT drivers. Switching to "EtherTalk Alternative" in the Network control panel works, and the Chooser, AppleShare and MacIP are all fine over the Wi-Fi/Ethernet.
• Then the next restart bombs with "address error" right after "Welcome to Macintosh", every time, and holding Shift doesn't help. The usual way out is to edit the disk from another machine.
• It happens with any AppleTalk 58 tried (58.0, 58.0.2, 58.1.4) and EtherTalk 2.5 or 2.5.7. The common part is the DaynaPORT SCSI/Link driver, v1.2.5f1, which the DaynaPORT 7.5.3 installer puts in the System file as .ENET0.

Others have hit it: Help with AppleTalk Connection on MacPlus using Zuluscsi (68kMLA, 2025).

Before doing any work, two routines in the driver, drvrCtlShell and ServiceTimer, check how much stack is left. Besides calling _StackSpace, each one reads the long at the address held in the low-memory global CurStackBase ($0908):

MOVE.L  CurStackBase,A0
MOVE.L  (A0),D5          ; read through CurStackBase
SUB.L   (A1),D5

CurStackBase is set up when the first application starts. During startup it is still $FFFFFFFF. A long read from an odd address is an address error on a 68000. On a 68020 or later a misaligned read is legal, which is likely why only the 68000 Macs crash.

AppleTalk opens .ENET0 during startup only when EtherTalk is selected. Picking EtherTalk later from the Finder works, because by then CurStackBase is valid.

The cause was found by reproducing the crash in the Snow emulator, which emulates a DaynaPORT SCSI/Link, and stopping on the address error in its debugger.

Each read is replaced with the _StackSpace result the driver already has in a register. The instructions are the same size, so nothing else moves. The driver still insists on at least $400 bytes of free stack.

Both sites are preceded by 2D48 FFF8 226E FFFC. The tool checks that context before writing.

You need Python 3, and nothing else. Work on a copy of your disk image, or keep a backup.

python3 patch_enet0.py "HD10_512 System 6.0.8.hda"            # report only
python3 patch_enet0.py "HD10_512 System 6.0.8.hda" --write    # patch

• It takes a whole disk image with an Apple partition map (BlueSCSI, ZuluSCSI and PiSCSI .hda files), a bare HFS volume, or, with --rsrc, a resource fork on its own (for example System/..namedfork/rsrc copied off a modern Mac).
• It patches every file in the blessed System Folder that holds a DRVR named .ENET0 with this code, normally System and any copies of it. --all looks at the whole volume instead.
• It changes 4 bytes per site and nothing else. Other drivers called .ENET0 (Asante and others) are left alone, and so is a file that is already patched.
• Installer disk images, such as the DaynaPORT 7.5.3 .img, are not opened. If you reinstall the DaynaPORT driver, patch the System again afterwards.

Do this on a System that is not the one you are running: one on another disk, or in an emulator.

1. Open the System file in ResEdit, then the DRVR resources, and select .ENET0 (ID 47 on the System we patched).
2. Open it with the hex editor (Resource → Open Using Hex Editor).
3. At offset $060E, check for 2810 9891 and change it to 2806 4E71.
4. At offset $19F8, check for 2A10 9A91 and change it to 2A07 4E71.
5. Save, then restart with EtherTalk selected.

• Snow (commit 245ac18) as a Mac Plus with 4 MB and an emulated DaynaPORT. The unpatched System bombs at startup with EtherTalk selected. Patched, it reaches the Finder on restarts and on a cold boot. Going back to LocalTalk still works.
• A real Mac Plus, 4 MB, System 6.0.8, BlueSCSI v2 (Pico W, firmware 2026.03.01) with Wi-Fi DaynaPORT, AppleTalk 58.0.2, EtherTalk Phase 2 2.5.7 and Network 3.0.1. Patched, it starts up on EtherTalk from a cold boot and a restart. Over EtherTalk, the Chooser finds the netatalk server, AppleShare mounts it, and MacIP works.

Not tested: the SE, the Classic, and real DaynaPORT SCSI/Link hardware. They run the same driver on the same CPU, so they should behave the same. Reports welcome.

No Dayna or Apple code is in this repository. The tool carries only the bytes it looks for and the bytes it writes. Don't redistribute patched drivers or System files; patch your own.

MIT, see LICENSE.